chore(standards): synced file(s) with hallelx2/dev-standards - #7

🏁 Script executed:

#!/bin/bash
set -euo pipefail

echo "== candidate files =="
git ls-files | rg '(^|/)(copilot-instructions\.md|agents|instructions)' || true

echo
echo "== .github/copilot-instructions.md =="
if [ -f .github/copilot-instructions.md ]; then
  nl -ba .github/copilot-instructions.md | sed -n '1,120p'
fi

echo
echo "== .github/agents =="
if [ -d .github/agents ]; then
  find .github/agents -maxdepth 3 -type f -print | sort | while read -r f; do
    echo "--- $f"
    nl -ba "$f" | sed -n '1,160p'
  done
fi

echo
echo "== .github/instructions =="
if [ -d .github/instructions ]; then
  find .github/instructions -maxdepth 3 -type f -print | sort | while read -r f; do
    echo "--- $f"
    nl -ba "$f" | sed -n '1,160p'
  done
fi

Repository: hallelx2/pdftable

Length of output: 601

🏁 Script executed:

#!/bin/bash
set -euo pipefail

echo "== .github/copilot-instructions.md =="
if [ -f .github/copilot-instructions.md ]; then
  awk '{printf "%6d  %s\n", NR, $0}' .github/copilot-instructions.md | sed -n '1,120p'
fi

echo
echo "== custom agent files =="
for f in .github/agents/*.agent.md; do
  [ -f "$f" ] || continue
  echo "--- $f"
  awk '{printf "%6d  %s\n", NR, $0}' "$f" | sed -n '1,180p'
done

echo
echo "== instruction files =="
for f in .github/instructions/*.instructions.md; do
  [ -f "$f" ] || continue
  echo "--- $f"
  awk '{printf "%6d  %s\n", NR, $0}' "$f" | sed -n '1,160p'
done

Repository: hallelx2/pdftable

Length of output: 11865

🌐 Web query:

GitHub Copilot custom agents applyTo path-specific instruction files automatic selection documentation

💡 Result:

In GitHub Copilot, path-specific instruction files are configured using *.instructions.md files, which allow you to define instructions that are applied automatically based on the files or directories currently being accessed [1][2][3]. Key details for implementation include: 1. Storage Location: These files should be stored within or below the .github/instructions directory in your repository [1][4][5]. 2. Configuration: Each .instructions.md file must include a YAML frontmatter block at the start of the file that defines the applyTo property [1][3]. This property uses glob syntax to determine which files the instructions apply to [1][2][3]. Example configuration: --- applyTo: "app/models//*.rb" --- 3. Automatic Selection: GitHub Copilot automatically selects and applies these instructions when the path of the file being worked on matches the glob pattern specified in the applyTo field [1][3]. If no applyTo property is defined, the instructions will not be applied automatically, though they may still be available for manual selection in some interfaces [3]. 4. Multiple Patterns: You can specify multiple patterns within the applyTo field by separating them with commas (e.g., applyTo: "/*.ts,/*.tsx") [1][2]. 5. Scope and Precedence: When a path matches, these path-specific instructions are used alongside repository-wide custom instructions (defined in .github/copilot-instructions.md) if they exist [1][5]. You can verify which instructions were applied by checking the References section of a Copilot chat response [3]. This functionality is supported in various Copilot features, including Copilot Chat in IDEs like Visual Studio Code and Visual Studio, as well as the Copilot cloud agent [4][6]. While custom agents (defined in files like AGENTS.md) and path-specific instructions both serve to customize behavior, they are distinct mechanisms; custom agents define broader agent profiles, whereas *.instructions.md files provide targeted, file-context-aware instructions [4][5][7].

Citations:

• 1: https://docs.github.com/en/copilot/how-tos/copilot-on-github/customize-copilot/add-custom-instructions/add-repository-instructions
• 2: https://docs.github.com/en/copilot/how-tos/copilot-cli/customize-copilot/add-custom-instructions
• 3: https://code.visualstudio.com/docs/agent-customization/custom-instructions
• 4: https://docs.github.com/en/copilot/reference/custom-instructions-support
• 5: https://docs.github.com/en/copilot/concepts/prompting/response-customization?tool=eclipse
• 6: https://docs.github.com/en/copilot/tutorials/customization-library/custom-instructions/your-first-custom-instructions
• 7: https://docs.github.com/en/copilot/concepts/agents/copilot-cli/about-custom-agents

🌐 Web query:

GitHub Copilot custom agents *.agent.md automatic selection agents panel profile selection applyTo instructions

💡 Result:

GitHub Copilot custom agents are defined using Markdown files with the .agent.md extension [1][2]. These files use YAML frontmatter to configure the agent's identity, behavioral instructions, and capabilities [3][4]. Automatic Selection and the Agents Panel GitHub Copilot can automatically select and use a custom agent based on the task context [5]. Key configuration properties in the .agent.md file control this behavior: - disable-model-invocation: If set to true, this prevents Copilot from automatically using the agent based on task context; the agent must then be selected manually [5]. - user-invocable: If set to false, the agent cannot be manually selected by a user and is restricted to programmatic access [5]. - infer (Retired): Previously used to control automatic selection; it is now recommended to use disable-model-invocation and user-invocable instead [5]. In IDEs and GitHub interfaces, users can typically select agents manually from an agents panel, dropdown, or tab when initiating a new session [6][7][8]. Instructions and applyTo While custom agents use .agent.md files for their core definition [1][4], separate instruction files often use the *.instructions.md format [9][10]. These instruction files utilize the applyTo property to manage scope [9][11]: - applyTo: This property accepts glob patterns to specify which files or directories the instructions apply to [9][11][10]. For example, applyTo: "/*.ts" would apply the instructions to all TypeScript files [11][10]. If this property is omitted, the instructions may not be applied automatically [9]. - Custom Agent Instructions: Within an .agent.md file, the behavioral instructions are defined in the Markdown content below the YAML frontmatter [4][12]. These instructions guide the agent's expertise, constraints, and behavior during its execution [4][2]. In summary, .agent.md files define the custom agent itself, while *.instructions.md files are often used for repository-wide or path-specific behavioral rules governed by the applyTo property [9][13][10].

Citations:

• 1: https://code.visualstudio.com/docs/agent-customization/custom-agents
• 2: https://docs.github.com/en/copilot/how-tos/copilot-cli/customize-copilot/create-custom-agents-for-cli
• 3: https://github.com/github/docs/blob/main/content/copilot/how-tos/use-copilot-agents/coding-agent/create-custom-agents.md
• 4: https://docs.github.com/en/copilot/how-tos/copilot-on-github/customize-copilot/customize-cloud-agent/create-custom-agents
• 5: https://github.com/github/docs/blob/main/content/copilot/reference/custom-agents-configuration.md
• 6: https://docs.github.com/en/copilot/how-tos/copilot-on-github/use-copilot-agents/overview
• 7: https://docs.github.com/en/copilot/how-tos/copilot-cli/use-copilot-cli/invoke-custom-agents
• 8: https://github.com/github/docs/blob/main/content/copilot/concepts/agents/cloud-agent/agent-management.md
• 9: https://code.visualstudio.com/docs/agent-customization/custom-instructions
• 10: https://docs.github.com/en/copilot/how-tos/copilot-on-github/customize-copilot/add-custom-instructions/add-repository-instructions
• 11: https://docs.github.com/en/copilot/how-tos/copilot-cli/customize-copilot/add-custom-instructions
• 12: https://docs.github.com/en/copilot/how-tos/use-copilot-agents/cloud-agent/create-custom-agents-in-your-ide?tool=vscode
• 13: https://code.visualstudio.com/docs/agents/guides/customize-copilot-guide

🏁 Script executed:

#!/bin/bash
set -euo pipefail

printf 'Tracked files relevant to Dependabot/workflows:\n'
git ls-files | rg '(^|/)\.github/(dependabot\.yml|workflows/|pyproject\.toml|requirements|setup\.py|poetry\.lock|Pipfile\.lock)' || true

printf '\nCurrent .github/dependabot.yml:\n'
cat -n .github/dependabot.yml

printf '\nSearch for python dependency scanning declarations:\n'
rg -n "python|pip|safety|bandit|security|oss-supplier|dependency|dependabot|package-ecosystem" .github -S || true

printf '\nSearch for pip ecosystems in dependabot files:\n'
rg -n "package-ecosystem:\s*(pip|poetry|requirements)" .github || true

Repository: hallelx2/pdftable

Length of output: 7039

🌐 Web query:

GitHub Dependabot package-ecosystem pip depends on requirements.txt setup.py pyproject.toml

💡 Result:

To configure Dependabot to monitor your Python dependency files, use the pip package ecosystem in your .github/dependabot.yml file [1][2][3]. Dependabot supports requirements.txt, setup.py, and pyproject.toml files under this single ecosystem [4][5][6]. Configuration Details: - Ecosystem Name: Use package-ecosystem: "pip" [1][2][6]. - File Support: Dependabot monitors requirements.txt (any .txt file), setup.py, and pyproject.toml (if it follows PEP 621) when configured with the pip ecosystem [5][6]. It also supports related files like setup.cfg [5]. - Directory Configuration: Specify the directory where these files are located (e.g., directory: "/") [3]. To ensure Dependabot scans nested directories, you can use patterns like directory: "//*" [7]. Common Setup: A standard dependabot.yml configuration for a Python project typically looks like this [3]: version: 2 updates: - package-ecosystem: "pip" directory: "/" schedule: interval: "weekly" Important Considerations: - Grouped Updates: If you have multiple dependency files (e.g., both a pyproject.toml and a requirements.txt) and want them updated together, you may need to use Dependabot's grouping feature to prevent separate, uncoordinated pull requests [7][4]. - Limitations: Dependabot's ability to keep requirements.txt files synchronized with pyproject.toml changes—especially if the requirements file is generated by an external tool like pip-compile—can vary [8][9]. In some cases, Dependabot may update the pyproject.toml but not the associated requirements.txt if the relationship between the two is not natively recognized by its update logic [9]. If you rely on external tools to sync these files, you may need to manage those updates outside of standard Dependabot version updates or ensure the files are in locations Dependabot consistently crawls [7][9].

Citations:

• 1: https://docs.github.com/en/code-security/reference/supply-chain-security/dependabot-options-reference
• 2: https://help.github.com/en/enterprise-server@3.5/code-security/dependabot/dependabot-version-updates/configuration-options-for-the-dependabot.yml-file
• 3: https://docs.github.com/en/copilot/tutorials/copilot-cookbook/analyze-security/manage-dependency-updates
• 4: https://til.simonwillison.net/github/dependabot-python-setup
• 5: https://github.com/dependabot/dependabot-core/blob/748aac6e/python/lib/dependabot/python/file_fetcher.rb
• 6: https://docs.github.com/en/enterprise-server@3.13/code-security/dependabot/ecosystems-supported-by-dependabot/supported-ecosystems-and-repositories
• 7: pip configuration does not recurse with pyproject.toml files dependabot/dependabot-core#14569
• 8: How to get updates for a pyproject.toml/requirements.txt setup? dependabot/dependabot-core#9455
• 9: pip no longer updates requirement files along with pyproject dependabot/dependabot-core#11750

🌐 Web query:

site:docs.github.com/dependabot/generate-dependabot.yml gomod npm pip

💡 Result:

Use these package-ecosystem values in .github/dependabot.yml:

version: 2
updates:
  - package-ecosystem: "gomod"
    directory: "/"
    schedule:
      interval: "weekly"

  - package-ecosystem: "npm"
    directory: "/"
    schedule:
      interval: "weekly"

  - package-ecosystem: "pip"
    directory: "/"
    schedule:
      interval: "weekly"

gomod is for Go modules; npm covers npm, Yarn, and pnpm; pip also covers pipenv and Poetry projects. [1][2]

🏁 Script executed:

#!/bin/bash
set -euo pipefail

echo "Tracked workflow file location:"
git ls-files .github/workflows/security*

echo
echo "Relevant workflow content:"
if [ -f .github/workflows/security.reusable.yml ]; then
  nl -ba .github/workflows/security.reusable.yml | sed -n '1,120p'
fi

echo
echo "Search for Semgrep image references:"
rg -n "semgrep/semgrep|image: " .github/workflows/security.reusable.yml || true

Repository: hallelx2/pdftable

Length of output: 327

🏁 Script executed:

#!/bin/bash
set -euo pipefail

echo "Relevant workflow snippets:"
awk '{printf "%8d  %s\n", NR, $0}' .github/workflows/security.reusable.yml | sed -n '1,120p'

echo
echo "Semgrep image references in workflow:"
grep -n "semgrep/semgrep\|image:" .github/workflows/security.reusable.yml || true

echo
echo "Check whether image reference has a digest:"
python3 - <<'PY'
from pathlib import Path
for line in Path(".github/workflows/security.reusable.yml").read_text().splitlines():
    stripped = line.strip()
    if stripped.startswith("image:") or stripped.startswith("image= "):
        value = stripped.split("=", 1)[1] if "=" in stripped else stripped.split(None, 1)[1]
        print(value, "has_digest:", "@" in value.split()[0])
PY

Repository: hallelx2/pdftable

Length of output: 5446

🏁 Script executed:

#!/bin/bash
set -euo pipefail

printf '--- workflow excerpt ---\n'
sed -n '90,140p' .github/workflows/security.reusable.yml 2>/dev/null || true

printf '\n--- pip-auss usages ---\n'
rg -n "pip-audit|projects_file|requirement|dependencies_file|bandit" .github/workflows || true

printf '\n--- repository manifest files ---\n'
git ls-files | rg '(^|/)(requirements[^[:space:]]*\.txt|pyproject\.toml|setup\.py|setup\.cfg|Pipfile|poetry\.lock|uv\.lock|Pipfile\.lock)$' || true

Repository: hallelx2/pdftable

Length of output: 246

🌐 Web query:

pip-audit command line documentation pip-audit . local project pyproject.toml requirements.txt default behavior no arguments

💡 Result:

The pip-audit tool is a vulnerability scanner for Python projects that audits dependencies against known vulnerabilities [1][2]. Its behavior depends on the arguments provided or the presence of a specific project path [3][4]. Default Behavior (No Arguments) When run without any arguments (pip-audit), the tool defaults to auditing the current active Python environment [3][5]. It inspects the installed packages in the environment and checks them against vulnerability databases [2]. Auditing Requirements Files To audit specific dependency files, use the -r or --requirement flag [3][4]. This flag can be used multiple times to audit multiple files (e.g., pip-audit -r requirements.txt -r dev-requirements.txt) [3][4]. pip-audit supports scanning requirements.txt files [4][2]. Auditing Local Projects You can audit a local project by providing its path as a positional argument [3]. When a project path is provided, pip-audit searches for specific "project" files, such as pyproject.toml [4]. Key Flags and Options -l, --local: Limits the audit to dependencies installed in the local environment, excluding globally installed packages if applicable [3][4]. --locked: Used when auditing from a project path to specifically audit lock files (currently supporting formats like pylock.*.toml) [3][4]. -f FORMAT, --format FORMAT: Specifies the output format (e.g., columns, json, cyclonedx-json, cyclonedx-xml, markdown) [6][3]. -s SERVICE, --vulnerability-service SERVICE: Selects the vulnerability service to use (options include osv, pypi, esms) [6][3]. -S, --strict: Causes the audit to fail if dependency collection fails for any dependency [6][3]. For detailed usage information, you can run pip-audit --help in your terminal [3][4].

Citations:

• 1: https://pypi.org/project/pip-audit/
• 2: https://stackharbor.com/en/knowledge-base/python-pip-audit-safety/
• 3: https://pypi.org/project/pip-audit/2.10.0/
• 4: https://github.com/pypa/pip-audit
• 5: https://discuss.python.org/t/towards-a-pip-audit-subcommand-for-vulnerability-analysis-management/17681?page=2
• 6: https://github.com/pypa/pip-audit?tab=readme-ov-file

🏁 Script executed:

#!/bin/bash
set -euo pipefail

printf '%s\n' '--- workflow excerpt ---'
sed -n '90,145p' .github/workflows/security.reusable.yml

printf '%s\n' ''
printf '%s\n' '--- pip-audit/bandit usages ---'
rg -n "pip-audit|requirement|dependencies_file|bandit" .github/workflows || true

printf '%s\n' ''
printf '%s\n' '--- repository manifest files ---'
git ls-files | rg '(^|/)(requirements[^[:space:]]*\.txt|pyproject\.toml|setup\.py|setup\.cfg|Pipfile|poetry\.lock|uv\.lock|Pipfile\.lock)$' || true

Repository: hallelx2/pdftable

Length of output: 3007

• AGENTS.md#L32-L34 (this comment)
• .github/copilot-instructions.md#L15-L18
• .github/instructions/security.instructions.md#L8-L10
• .github/agents/security-reviewer.agent.md#L13-L16